Event subscription and notification in network environments is becoming increasingly commonplace and important. Event subscription generally allows a first network entity to subscribe to event notifications from a second entity. Common examples of events include “presence” and “location;” however, the number and types of events are endless. For instance, conventional instant messaging services permit a first user to subscribe to a presence event for a second user. As such, during the period of the subscription, the first user receives updates as to the presence status (e.g., online or offline) of the second user. The subscription may be for a single inquiry, which will return a response of “present” or “not present” for the second user. The subscription may also be for a set period of time, which may result in multiple updates, or for other options (e.g., status change notifications, ongoing notifications, etc.)
Various protocols may be used for event subscription and notification. For example, the Session Initiation Protocol (SIP) may be used for such purposes (see, e.g., IETF request for comment document RFC 3261, entitled: SIP: Session Initiation Protocol, July 2002, the contents of which are hereby incorporated by reference in its entirety). SIP was generally developed to allow for initiating a session between two or more endpoints in the Internet by making these endpoints aware of the session semantics. Accordingly, devices (or users that run certain applications on these devices) are registered with the SIP backbone so that an invitation to a particular session can be correctly delivered to these endpoints. To achieve this, SIP provides a registration mechanism for devices and users, and it applies mechanisms such as location servers and registrars to route the session invitations appropriately. Although SIP is primarily a tool for initiating a communication session between endpoints, extensions to SIP have been proposed to provide event registration and trigger notification (see e.g., IETF document RFC 3265, SIP-Specific Event Notification, July 2002, the contents of which are hereby incorporated by reference in its entirety).
The SIP event framework, which would enable event-based information provisioning to any node in the Internet, is supposed to become a key element within the SIP infrastructure. Apart from providing information regarding certain events, such as presence or location, the SIP event framework provides the means for an event-based service invocation system. In this regard, there are numerous techniques in place for performing remote procedure invocation in distributed systems, such as RPC's (Remote Procedure Calls), CORBA (Common Object Request Broker Architecture) and Jini™. These techniques, however, typically aim at distributed software problems and remote procedure calls on a much lower software level. And in contrast to procedure invocation, service invocation typically occurs on a much higher level of abstraction. Also, conventional techniques such as RPC's, COBRA and Jini™ typically require a complex infrastructure present on the device performing the service invocation.
Consider, for example, a service provider offering an online auction service, and a user desiring to access this service to sell a car. Conventionally, a service invocation by the user starts an auction with the service provider for the car, and the service is seen as terminated after the car is sold. But even more, the service provider can provide information to the user about the progress of the service. For example, the service provider may provide the user with information relating to any bids that the service provider has received for the car, the amount of the bids, and so forth. In this regard, service parameters for the service invocation may relate, for example, to price and other information regarding the car and the command to start the auction for the car.
Another example relating to service information relates to remote recording of a video stream. Consider, then, that a mobile user desires to remotely start a service with a home entertainment system to record a certain television program at a certain time in the future. In such an instance, the home entertainment system may provide the service to the user, and once the service is started, notify the user regarding its progress (e.g., “recording not yet started” or “recording”) and/or its ending. As can be seen, then, targeted service invocations typically aim at a much higher level than procedural invocation such as in RPC's.